Present day data communication networks, both wireless and wire-line, have a requirement to transfer data between communication units. Data, in this context, includes many forms of communication, such as speech, multimedia, signalling, etc. Typically, such data communication needs to be effectively and efficiently transported, in order to optimise use of limited communication resources.
Due to the recent growth in communications, particularly in Internet and wireless communications, there exists a need to provide improved data transfer techniques, where a particular quality of service of the transmitted data is often required or desired by the end user.
The European Telecommunication Standards Institute (ETSI) has defined a number of communication standards with the aim that a number of manufacturers are able to provide equipment that supports the same technology and are able to inter-operate with other equipment compliant with that standard. One such data communication standard developed by ETSI is the Terrestrial Digital Video Broadcasting (DVB-T) standard (ETSI EN 300 744), which has been developed for digital television sets and set-top boxes.
A recent variation of the DVB-T standard that has been adopted to incorporate enhanced features to allow improved reception of digital video broadcasting services for mobile devices is the digital video broadcasting—handset DVB-H standard. A DVB-H unit is battery powered, and the nature of the broadcast transmission offers a possibility to the DVB-H unit to repeatedly power off components/circuits of the DVB-H unit's receiver chain to increase battery life. It is anticipated that DVB-H units may receive transmissions at a variety of locations, such as: indoor, outdoor, as a pedestrian, within a moving vehicle, etc.
One feature that has been incorporated within the DVB-H standard that facilitates this aim of mobile reception is the use of multi protocol encapsulated—forward error correction (MPE-FEC) of received data. MPE-FEC facilitates recovery of data by a receiver in situations of high data-packet loss, which can occur when a receiver is in a changing environment, for example when a receiver is moving. MPE-FEC regroups data into blocks (MPE-FEC frames) and performs forward error correction on these data blocks. For an efficient error correction mechanism, a common approach is to have MPE-FEC frames larger than 512 Kbits. Thus, a receiver operating within a DVB-H compatible system receives an MPE-FEC frame with up to 2 Mbit of data over a single channel in a relatively short time period, for example 200 millisecond.
It is also known that to save power, the DVB-H standard has incorporated a technique of ‘time-slicing’ 100, as illustrated in FIG. 1. Time slicing is a mechanism that regroups data into bursts 110. A burst is a quantity of data 125 that is sent in a small amount of time 115 termed a burst duration. The next burst is sent after a significant time delay, termed ‘off-time’ 120, and so on. During this period of time, bursts from other programs or applications may be sent. Thus, a burst 110 may utilise an increased burst bandwidth 130 for a burst duration 115, which is in excess of a constant bandwidth 135 available across all time periods. In this manner, the receiver is only activated when there is a burst. Generally, within the DVB-H standard, bursts and MPE-FEC frames correspond. This means that there are an integer number of complete MPE-FEC frames per burst.
Historically, DVB-T originally was meant for MPEG2 video transmitted in MPEG2 Transport Steam (TS). MPEG2 TS is protected with Reed Solomon (RS) Forward Error Correction (FEC) codes. Then application of Multi-protocol Encapsulation (MPE) decoding enables transport of Internet Protocol (IP) data packets. Thus, to cope with mobile propagation degradation, DVB-H introduced another layer of RS FEC called MPE-FEC. Here, only MPE blocks with correct cyclic redundancy check (CRC) are further processed by the MPE FEC decoder. If the CRC fails, the whole block is discarded. Zeros are then inserted at the proper byte positions in the RS code words, instead of the block data, and are marked as “unreliable”. If there are more than 64-unreliable byte positions in a RS code word, the RS decoder cannot correct anything, and therefore just outputs the bytes without error correction.
Referring now to FIG. 2, a known MPE-FEC decoder 200, as proposed in the EN 301 192 V1.4.1 standard, is illustrated. The MPE-FEC decoder comprises a demodulator 205 for demodulating a received signal, followed by an inner decoder 210 and outer decoder 215 for decoding the demodulated received signal. The inner decoder is a convolutional decoder. The reception is typically implemented using a soft-decision Viterbi decoder. This reduces the effect of thermal noise and interference on the quality of the received signal, as Viterbi errors are generally bursty in nature. A Reed-Solomon decoder is used as the outer decoder, which feeds the decoded, demodulated received signal into an MPEG2 Transport Stream (TS) de-multiplexer to de-interleave received data packets. The MPE data packets are then divided into IP datagrams 225, 240 and RS column data 230, 245. A typical table of MPE-FEC data is illustrated in FIG. 3. These MPE data packets are then input into the MPE-FEC decoder 250 to provide output corrected IP datagrams 255.
Referring now to FIG. 3, a known MPE-FEC table 300 contains redundant information that can be used to remove errors not corrected by the inner and outer decoders of FIG. 2. The MPE-FEC table 300 comprises an Application data table 310 comprising IP datagrams 310, some padding 315 and Application padding columns 320. In addition, an RS data table 335 comprises RS data 325 and punctured RS data columns 330. The 64 punctured RS data columns carry redundancy information of the Application data table 310. These columns facilitate recovering of lost sections with the method described below.
The specification EN 301 192, clause 9.3.3 suggests a method for MPE-FEC decoding as follows: “The number of rows in the MPE-FEC Frame is signalled in the time_slice_fec_identifier_descriptor. The number of padding columns in the Application data table is signalled in the header of each MPE-FEC block. The number of punctured RS columns can be calculated as 63−last_block_number, since last_block_number indicates the block number of the last block. As the block numbering is zero based, the indicated number is, thus, one less than the number of columns.
The Receiver introduces the number of padding bytes in the Application data table, as indicated in the MPE-FEC blocks. It marks these padding bytes as ‘reliable’. If the Receiver has received the last block of the Application data table correctly, i.e. the table_boundary_flag, it can mark any remaining padding bytes in the Application data table as reliable. If the Receiver did not receive the last block correctly it will have to assume that all byte positions after the last correctly received block until the first padding column is lost data, even if some of it effectively is padding, and mark the corresponding byte positions as unreliable. Since the number of padding columns is signalled the maximum number of padding bytes that could be marked as unreliable is equal to no_of_rows−1. The effect on coding performance because of such unreliable padding bytes is marginal.
All MPE and MPE-FEC blocks are protected by a CRC-32 code, which reliably detects all erroneous blocks. For every correctly received block belonging to the Application data table or to the RS data table, the Receiver looks in the block header for the start address of the data payload within the block and is then able to place the payload in the right position of the respective table.
After this procedure there are, in general, a number of remaining “holes”, which corresponds to lost blocks. All correctly received bytes, and Application data padding, can then be marked as “reliable” and all byte positions in the “holes”, and in the punctured RS columns, can be marked as “unreliable” in the RS decoding.
All byte positions within the MPE-FEC Frame (Application data table+RS data table) are now marked as either “reliable” or “unreliable”. With such MPE-FEC reliability (erasure) information the RS decoder is able to correct twice the number of erroneous or unreliable bytes, which means the code can correct up to 64 such bytes per 255-byte codeword.
If there are more than 64 unreliable byte positions in a row the RS decoder will not be able to correct anything and will therefore typically just output the byte errors without error correction. The Receiver will therefore have perfect knowledge about the positions of any remaining byte errors within the MPE-FEC frame after RS decoding. If a datagram is only partly corrected the receiver will be able to detect this and (optionally) discard this datagram.
In addition to the CRC-32, which detects erroneous blocks, the RS decoder also very reliably detects erroneous TS packets. If an MPEG-2 demultiplexer discards erroneous packets it could be designed not to build blocks, which contain lost TS packets. In this way, almost only correct blocks would be built and the role of the CRC-32 would be to provide additional error detection functionality, which normally is not needed. In very rare cases it may happen that the RS decoder fails to detect an erroneous TS packet, . . . and that an erroneous block therefore could be constructed. In these cases the CRC-32 would discover such a block error.”
Thus, according to EN 301 192 V1.4.1, ‘Digital Video Broadcasting (DVB); DVB specification for data broadcasting’: “if there are more than 64 unreliable byte positions in a row the RS decoder will not be able to correct anything”. Any such limitation in performance means, amongst other drawbacks, a reduced cell coverage for a cellular data network, a lower maximum operating speed, etc
Thus, a need exists for an improved data communication unit comprising a decoder, a method of decoding and data communication network.